Various incidents occur that require substantial information processing. Such incidents may involve, for example, a car accident in which an insurance claim must be processed. The processing of the claims and information related to these incidents tends to be high volume. Each incident may have several people or other entities associated with it, and each individual person will have contact information and other details that need to be collected and processed. There are concerns and issues that can arise with respect to the gathering, handling, and maintenance of such contact information.
When information is obtained regarding an incident or those individuals involved in an incident, the information will likely be associated with the incident, but will not necessarily be associated with a general address book that may be otherwise maintained by those who process the incident. Some of this contact information may be relevant only to the specific incident at issue, while other information may be useful in processing other incidents and therefore must persist within the system beyond the duration of the incident in a way that is useful for processing future events. In addition, multiple people may process or evaluate an incident and therefore the relevant incident information must be readily, accurately, and easily available to all individuals needing access to such information. Further, it is generally necessary to process the information in an efficient manner for the system to be effective.
Those skilled in the art are familiar with the existence of computer-based processing systems having an address book. It is often useful to have a centralized address book containing entries that persist in the system for an extended time. Such information can provide context for future business decisions and data for ongoing business operations. It can also provide a single point of reference to ensure that individuals can be correctly identified, for example to indicate that two contact records with the same name involved in two separate incidents actually refer to the same entity. Such an address book generally contains relevant helpful contact information that can be used when managing incident-related work. This information may include entries such as a family or entity name, a date of birth, an age, an occupation, a telephone number or a mailing address, to name a few. Depending upon the system such address book entries may or may not be associated with a specific incident.
Notwithstanding the existence of these computer-based address books, numerous issues exist with respect to their configuration and application. When information regarding an incident is first received, it generally comprises a disconnected collection of data that must be efficiently and intuitively sorted and processed. For many reasons, it may not be possible to know at the time of collecting the information which entity it refers to (if any) in the address book. For example, the person collecting the information may not have access to the address book and therefore has no way of knowing whether the collected information relates to an address book entity.
One approach to organizing contact information might be to provide for a single, common storage capability for the contact information. A single storage capability, however, will only provide for one address book, with no ability to store contacts that are associated only with a given incident (for example, a witness to an accident). Such a system would force all contacts to be stored in the common address book, which makes it difficult to distinguish between permanently valuable contact information (for example, as relates to a customer) and information that is valuable only within the context of an incident. Therefore, it is often useful to store the incident-related contact information separately from information in the address book.
Another problem with a single storage platform is that the address book does not provide any way for incident-specific contact information to be stored separately and distinctly from the permanent information stored in the address book. This is useful, for example, for holding a temporary address for correspondence related to the incident separate from any permanent address book information.
In addition, the information that is stored in the address book is typically required to be of higher quality. Incident-related contact information, however, may be gathered under sub-optimal conditions (for example, in a post-catastrophe environment) and, if forced to be stored in the address book, can pollute the data quality of the address book (for example, by introducing duplicate records as a result of a misspelling). Similarly, many companies may wish to impose higher data quality requirements on the address book (for example, requiring a zip code or a social-security number) than on the incident-related record. As a result of these higher data quality requirements, companies may wish to restrict the numbers of people who can make changes to the address book. Therefore, few people would be allowed to update the address book. Providing separate storage systems for the address book and the incident-related contact information would allow the system to restrict access for the address book while still allowing many people to enter incident-related contact information.
In light of the above-listed issues with a single, common storage capability, it may be helpful to have incident-related contact information stored separately from address book information. Further, there are times when contact information associated with an incident may need to be copied over or compared to an address book or the address book information may need to be associated with a specific incident. The comparison or updating of information between the records may be facilitated by the existence of a link between the address book and the incident information. This link may also be used to retrieve information from the linked address book record and to facilitate decision making with respect to the link.
Present computer-based address books do not provide for the effective management of incident-related work. These address books are often used by a relatively untrained (with respect to the intricacies of a computer-based processing system) work force, and therefore an intuitive approach to address book management is preferred. Further, present address books do not provide for an uncomplicated and user-friendly method of comparing or linking information. Further yet, many present address books may allow a user to inadvertently enter different or incorrect information without further notifying the user of the difference or error. Other systems do not allow information to be sorted so that certain information may persist and be stored within the system.
Simply put, present computer-based address books do not provide for an intuitive and efficient address book for supporting the managing of incident-related work that will process and organize relevant information
Skilled artisans will appreciate that elements in the figures are illustrated for simplicity and clarity and have not necessarily been drawn to scale. For example, the dimensions and/or relative positioning of some of the elements in the figures may be exaggerated relative to other elements to help to improve understanding of various embodiments of the present invention. Also, common but well-understood elements that are useful or necessary in a commercially feasible embodiment are often not depicted in order to facilitate a less obstructed view of these various embodiments of the present invention. It will further be appreciated that certain actions and/or steps may be described or depicted in a particular order of occurrence while those skilled in the art will understand that such specificity with respect to sequence is not actually required. It will also be understood that the terms and expressions used herein have the ordinary meaning as is accorded to such terms and expressions with respect to their corresponding respective areas of inquiry and study except where specific meanings have otherwise been set forth herein.